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ABSTRACT 


loT revolutionizes academia as well as indus- 
try. An increasing number of interconnected 
smart devices are gradually changing the urban 
lifestyle, among which, voting machines are one 
of the most widely used smart devices. However, 
the existing voting protocols for loT are barely sat- 
isfactory, in the sense that most of them are cen- 
tralized and subject to fairness issues. Moreover, 
the embedded softwares in voting machines are 
susceptible to internal vulnerabilities and exter- 
nal attacks. To address these issues, in this article, 
we propose a framework of a blockchain-based 
self-tallying voting system with software updates 
in decentralized loT, which is fully decentralized 
and fair. In the proposed system, everyone can 
compute the final election results by collecting 
the ballots on the blockchain with equal privilege. 
Voting machines achieve self-tallying voting func- 
tionality in decentralized loT systems and each 
entity in the system can obtain the voting results. 
Vendors deploy smart contracts to publish new 
patches securely and reliably. We implement a 
prototype of the proposed framework on laptops 
and mobile phones respectively to demonstrate 
its practicality. 


INTRODUCTION 


The Internet of Things (loT) ecosystem [1, 2] is 
a network consisting of billions of smart devic- 
es such as sensors and actuators, connecting 
without any human interaction. The embedded 
software and hardware in the smart devices and 
the connectivity among them allow the loT sys- 
tem to collect, share and exchange data. Typi- 
cal loT applications such as smart city and smart 
home make loT pervasive and closer to people’s 
daily life, and currently, believe it or not, loT is 
experiencing a new wave of prosperity and is 
also changing the urban lifestyle. According to 
iot-analytics.com, which is a company engaging 
in intelligence gathering about the loT industry 
and publishing valuable digital reports, in August 
2018 the number of active loT devices worldwide 
has exceeded 7 billion, driven by both consum- 
ers and enterprises, and this number is estimated 
to become 10 billion by 2020 and 22 billion by 
2025 (https://iot-analytics.com/state-of-the-iot-up- 
date-q1-q2-2018-number-of-iot-devices-now-7b/). 
Voting machines are one of the most widely 
used smart devices in loT. According to Pamela 


Smith, president of election integrity organization 
verified voting, voting machines are widely lever- 
aged in e-voting, such as in Louisiana, Georgia, 
New Jersey and so on (https://www.esecurityplan- 
et.com/network-security/vulnerable-voting-ma- 
chines-yet-another-iot-device-to-secure.html). The 
advantages of electronic voting are prominent in 
the sense that they are convenient and save much 
energy and cost in casting and tallying the votes. 
Moreover, thanks to the development of science 
and technology, the financial costs to produce 
voting machines are much lower and thus they 
are widely used in loT applications, such as the 
leader election in wireless sensor networks. How- 
ever, the existing voting protocols suffer from the 
following defects. First, most of the existing vot- 
ing schemes are centralized. To be more specific, 
there is a central party that organizes the whole 
election and also collects and tallies the ballots. 
This is naturally not suitable in decentralized loT 
applications. A decentralized loT system over- 
comes the drawbacks of a centralized loT frame- 
work such as single-point-of-failure, and can also 
enjoy efficient peer-to-peer communication. Thus, 
a decentralized voting protocol for decentralized 
loT scenarios is more suitable than the centralized 
protocols. Second, the existing voting systems are 
subject to fairness issues. In traditional central- 
ized e-voting systems, the central party, which tal- 
lied the votes, has the priority to obtain the final 
result, which is undesirable. Even in self-tallying 
voting systems, where there is no central party 
involved and each party can do the tally when 
all the ballots are cast, it is still non-trivial to deal 
with fairness issues. To be more specific, the final 
result in self-tallying voting schemes is computed 
with all the ballots, thus, the last voter will have 
the priority to access the voting result ahead of 
time, which is dubbed adaptive issues. If the last 
voter refuses to cast their vote, then it is hard for 
the other users to get the final result, which is the 
abortive issues. Third, voting machines are vul- 
nerable to malware and can be easily hacked, 
such as SQL injection flaws and and so on. It is 
said that voting machines become weak instead 
of smart when they are connected into the net- 
work as some unknown attacks will be carried out 
by adversaries. It is reported that nearly half of 
the voting machines suffered from vulnerabilities 
(https://www.wsj.com/articles/widely-used-elec- 
tion-systems-are-vulnerable-to-attack-report-. 
finds-1538020802). Therefore, the embedded 
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softwares in voting machines need to be updated 
to repair the internal vulnerabilities and to resist 
more external attacks. 


CONTRIBUTION 


The aim of this article is to address the issues 
mentioned above. Specifically, the contributions 
of this article are three-fold: 

e We introduce self-tallying voting protocols 
in decentralized loT for the first time. We 
also handle the software update problem 
in loT devices and propose the concept of 
a self-tallying voting system with software 
updates in decentralized loT. 

e We take advantage of consortium block- 
chain [3] to integrate the loT devices and 
the vendors (clouds) [4], and propose a 
framework of a blockchain-based self-tally- 
ing voting system with software updates in 
decentralized loT, which is fully decentral- 
ized and can also achieve fairness. Smart 
contracts are employed by the vendors to 
provide secure and reliable patches for the 
voting machines. 

e We implement the proposed framework 
with a demo on laptops and mobile phones 
respectively to show the efficiency of our 
protocol. 


RELATED WORK 


TRADITIONAL CENTRALIZED METHODS FOR E-VOTING 


Recall the traditional paper-ballot voting in real- 
world elections. A voter asks for a voting card 
with the candidates’ names from an official office, 
chooses the candidates they support by crossing 
the corresponding options on the voting card. The 
voter then puts the voting card in an opaque enve- 
lope made of carbon paper and seals it to make 
a ballot. To cast the ballot, the voter presents the 
envelope with their identity to the official office, 
where the voter is checked if registered and cast a 
vote already. But the office gets nothing about the 
vote itself. If the voter is registered at the office but 
does not cast a ballot yet, the office then stamps 
the envelope. In this way, the imprint of the stamp 
is visible on both the envelope and the voting card 
within. The voter posts the stamped envelop anon- 
ymously, free of charge, to a counting center who 
shuffles all received envelops, opens the envelops 
and counts the voting cards with an imprint of the 
official stamp. 

E-voting is the electronic version of paper- 
based voting systems, which can be classified into 
three categories. The first one is supervised vot- 
ing, also known as off-line voting, in which voting 
machines are usually located at polling stations 
but not connected, and voters are supervised 
physically by independent electoral authorities. 
The second one is hybrid voting where voters are 
supervised physically by election officials but the 
voting machines are Internet-connected. The last 
one is remote online voting, where the voters are 
unsupervised by election officials. Typically, the 
voters cast their ballots via the Internet using a 
personal computer or mobile phone. 

We review a well-know e-voting protocol due 
to Fujioka, Okamoto and Ohta with an abbrevi- 
ation FOO protocol [5]. There were no formal 
security models when this protocol was invent- 
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FIGURE 1. FOO protocol. 


ed in 1992. However, it is widely believed that 

the FOO protocol achieves the privacy property 

in spite of no security proofs for it. As shown in 

Fig. 1, three entities including an administrator, a 

counter and voters, are involved in the FOO vot- 

ing system. One can use a public board to replace 
the counter in some applications, since what the 
counter does is to create a list of ballots and pub- 
lish it. The authority is responsible for checking 

if a voter has the right to vote and generates a 

blind signature of the ballot for a voter. Briefly, 

the FOO protocol consists of the following steps: 

e A voter prepares their ballot, signs it and 
keeps a random value private. 

- A voter gets a certificate by authenticating 
themself to the administrator and obtains a 
blind signature on their ballot. 

e A voter submits their ballot along with the 
administrator’s signature to the counter 
anonymously. 

e The counter returns a voting number to the 
voter. 

* Upon closing the election, the voter sends 
their private random value to the counter 
anonymously. 


SECURITY REQUIREMENTS OF TRADITIONAL E-VOTING 


Some high level and important security properties 

of e-voting protocols are as follows: 

* Eligibility. Only authorized voters can vote, 
and can only vote once. 

e Ballot secrecy. Nobody can figure out how a 
voter voted, even if the voter tries to prove 
it. 

e Receipt-freeness. After the election, a voter is 
unable to prove how they voted. 

* Coercion-resistance. No one should be able 
to force a voter to vote in a certain way or 
abstain from voting. 

* Individual verifiability. A voter is able to verify 
if their ballot has been counted. 

e Universal verifiability. Anyone can verify if a 
tally is correctly computed from the ballots 
that were cast by legitimate voters. 
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FIGURE 2. System model of blockchain-based self-tallying voting system with soft- 
ware update in decentralized loT. 


e Fairness. No partial results are known ahead 
of schedule before the election is closed. 

* Robustness. Nobody can disrupt an election 
once it is started. 


CRYPTOGRAPHIC BUILDING BLOCKS 


A number of novel public-key cryptographic tech- 
niques were employed to achieve the target secu- 
rity properties of e-voting protocols mentioned 
above. We review some widely used techniques 
as follows. 

Commitments: A commitment is a digital 
equivalent of putting a voting card in an opaque 
envelope and sealing it. In such a way, nobody 
else can read the voting card until the envelope 
is opened (hiding) and the voter cannot modify 
the content of the voting card (binding) since the 
voter has committed the vote. 

Blind Signatures: A blind signature is useful in 
applications where a signer signs a message with- 
out getting to know the content of the message, 
and e-voting is such a scenario. In e-voting proto- 
cols, a voter commits their voting card. To make 
sure that only eligible voters cast ballots, the voter 
needs to authenticate themself to an authority, 
who signs the committed ballot without knowing 
the content of the ballot. Here, the authority has 
to use a blind signature instead of an ordinary dig- 
ital signature in the sense that the voter does not 
want to reveal the content of the ballot. 

Zero-Knowledge Proofs: Trust is one of the 
serious issues in e-voting. For example, a voter 
might encrypt a special message to get an 
unfair advantage for cheating, or the authority 
may announce a wrong voting result and so on. 


Zero-knowledge plays an important role to ensure 
one has done certain operations correctly without 
leaking more than the fact, which works in the fol- 
lowing way. Take the voter as an example. A bal- 
lot, as well as a proof that the ballot was correctly 
generated, are needed when a voter submits a 
ballot. The property of zero-knowledge indicates 
that the proof of the ballot being correctly gen- 
erated does not reveal the content of the ballot. 

Homomorphic Encryption: Homomorphic 
encryption enables one to perform an additional 
computation on ciphertexts in such a way that 
taking two ciphertexts as input and generates a 
new ciphertext for the “sum” of the two corre- 
sponding plaintexts. Homomorphic encryption 
is quite useful to achieve ballot privacy without 
affecting counting votes in e-voting protocols. 

Cryptographic Counter: A cryptographic 
counter allows a group of users to increment 
some specific values privately and robustly. 
Implementations of these counters rely on (fully) 
homomorphic encryption and with the help of 
other primitives such as zero-knowledge proofs. 
A typical process in voting with the cryptographic 
counter is as follows. The authority initializes the 
cryptographic counter and passes it to one of the 
voters. Each voter increments or randomizes it to 
vote and shows a proof to indicate their opera- 
tion. After that, the voter passes the counter to 
the next one. After all the voters cast their ballots, 
the authority decrypts and gets the final results. 

Mix-Nets: Mix-nets are another important tool 
to anonymize ballots in an e-voting protocol. 
Compared with zero-knowledge proofs, mix-nets 
can deal with ballots with arbitrary formats. A typ- 
ical implementation of mix-nets in e-voting is to 
shuffle all the ballots and re-encrypt all the ballots. 
In such a way, the ballots stay the same even if 
their ciphertexts are shuffled and the link between 
the ballots and the voters is hidden. 

Bulletin Boards and Blockchain: A public 
bulletin board is an information repository that 
is published for anyone in the system to check 
the validity of the shared data. Bulletin boards 
are widely used in cryptographic systems for 
secure verification. In an e-voting system, the 
bulletin board is responsible for recording some 
election-relative events, such as the public keys, 
the encrypted ballots, the tally results and so on. 
Blockchain is a global bulletin board, which is fully 
decentralized and tamper-resistant. Anyone in the 
system can access the blockchain freely to pub- 
licly audit the logged data. Such a tool can be 
a perfect overlay in designing self-tallying voting 
protocols. 


RELATED WORKS OF SELF-TALLYING VOTING PROTOCOLS 


The existing self-tallying voting protocols are not 
quite many. The concept of self-tallying election 
was proposed by Kiayias and Yung [6]. They pro- 
posed two schemes, in which one is suitable for 
boardroom elections and the other can be adapt- 
ed to large-scale elections. They also define the 
security requirements that a self-tallying election 
needs to satisfy. Later in 2004, Groth [7] pro- 
posed a self-tallying voting scheme and proved 
its security in a simulation-based model. Unfortu- 
nately, it does not offer efficient fault correction 
in the scheme. Hao et al. [8] presented a self-tally- 
ing voting scheme based on an anonymous veto 
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protocol, which is obtained from a clever mathe- 
matical transformation. Khader et al. [9] focused 
on the fairness issues in [8] and added another 
recovery phase, in which they ignored the bal- 
lots from the abortive voters. In 2017, McCorry 
et al. [10] proposed a blockchain-based self-tal- 
lying boardroom voting model, in which smart 
contract (http://ethereum.org/ethereum.html) is 
leveraged. They developed a prototype for the 
voting system. 


RELATED WORKS OF BLOCKCHAIN-BASED E-VOTING PROTOCOLS 


The contribution of blockchain in an e-voting sys- 
tem can be categorized into two aspects, to be 
a public bulletin board and to replace the cen- 
tral party. Most of the existing works on block- 
chain-based e-voting systems are in the first scope 
[11, 12]. In such scenarios, the function of the 
blockchain is elaborated above. Few works are in 
the second scope [10, 13] and the basic ideas are 
analyzed in the previous subsections. 


BLOCKCHAIN-BASED SELF-TALLYING VOTING SYSTEM 
WITH SOFTWARE UPDATE IN DECENTRALIZED IOT 


In this section, we first present the system model 
of a blockchain-based self-tallying voting system 
with software updates in decentralized loT. Then 
we introduce the workflow of the whole system. 


SYSTEM MODEL 


As illustrated in Fig. 2, there are five entities 
involved in the system model, which are a block- 
chain [14], a peer-to-peer (P2P) network, voting 
machines, loT gateways and vendors. The details 
are listed below. 

Blockchain: In our system, we leverage a con- 
sortium blockchain between the vendors and loT 
devices, in which the transaction throughput is 
high and the block generation time is adjustable 
[2]. Different from its public counterpart, partial 
control works on a consortium blockchain. In 
consortium blockchains, the nodes need regis- 
tration to participate in the system and thus it is 
also applicable to regulated purposes. Also, the 
required computational power is lower than that 
in the public blockchain. Blockchain in our sys- 
tem serves as a public bulletin board, which can 
be accessed by anyone in this system, to record 
all the modifications in the lifetime. First, the 
blockchain needs to enroll the voting machines 
when they first register in the system and realize 
device management. We define such transactions 
as Tregister. Second, the blockchain needs to col- 
lect the ballots from voting machines and make 
everyone in the system to get the final result at 
the same time to achieve self-tallying and fair- 
ness property. Such transactions related to Vote 
phase are denoted as Tyote. Third, in the software 
update phase, the vendors publish the patches 
on the Blockchain and issue incentives to some 
designated miners. These transactions are written 
as Tupdate- 

P2P Networks: A P2P network consists of lots 
of authorized terminals, which are called the min- 
ers. The miners are supposed to possess plenty 
of computational capacity and storage resources, 
whose responsibility is to generate new blocks 
with their “efforts.” All the miners run a managed 
consensus algorithm, such as Practical Byzan- 


tine Fault Tolerance (PBFT) or Tendermint [2], to 
achieve consistency and stability in the system. In 
our system, the P2P network is accessible by any 
user of the system and generates new blocks with 
different types of transactions. 

Voting Machines: Voting machines are the loT 
devices that can cast ballots with the embedded 
software provided by the vendors. They need to 
register when they first join the system. The gate- 
way will generate an IP address to identify each 
voting machine and send a Tregister transaction to 
the blockchain. The voting devices can generate 
a vote and cast ballots when needed. Also, the 
voting machines need to update the embedded 
software with the patches in the blockchain pro- 
vided by the vendors. 

loT Gateway: loT gateway is the key compo- 
nent to integrate the loT devices. loT gateway is 
composed of many routers, which perform multi- 
ple important functions, such as interconnect the 
devices, collect and forward captured data, trans- 
late the sensor protocol and more. loT gateway is 
also the bridge between the voting machines and 
vendors in our system. 

Vendors: Vendors are the service provid- 
ers of the voting machines, which also provide 
continuous revamp of their products and ser- 
vice offerings. When the vendors publish new 
updated software or patches for the voting 
machines, they generate a smart contract into 
the blockchain, and the corresponding voting 
machines will update the software embedded in 
the blockchain. 


SECURITY REQUIREMENTS OF BLOCKCHAIN-BASED 


SELF-TALLYING VOTING WITH SOFTWARE UPDATES 

A blockchain-based self-tallying voting system 

with software updates in decentralized loT needs 

to satisfy the following requirements. 

e Decentralization: There is no central party in 
the system. All the nodes in this system are 
equal in the sense that each node enjoys the 
same rights and services. 

e Fairness: No partial-tallying results are 
revealed before the end of the whole voting 
process [6]. 

e Self-Tallying: After all the voting machines 
cast their ballots, any entity in the system can 
do the tallying with the collection of all the 
ballots. 

e Ballot Secrecy: The knowledge of the bal- 
lots can only be accessible to the coalition of 
a subset of the other voting machines. The 
secrecy level is adjustable by choosing the 
proper size of the subset. 

* Software Update: The embedded software 
in the voting machines can be updated with 
the secure and reliable patches published by 
the vendors. 


WORKFLOW 


The details of a blockchain-based self-tallying vot- 
ing system with software updates in decentral- 
ized loT are as follows. As shown in Fig. 3, three 
phases are involved in the whole workflow, name- 
ly Register, Vote and Update. 

Register: All the voting machines need to reg- 
ister when they first enroll in the system. W.l.0.g, 
suppose there are n voting machines, VD4, «=, 
VD,, in our system. Each VD;(i € n) registers to 
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loT gateway to apply for a unique IP address in 
the intranet. Then with this IP address as a ran- 
dom seed, each voting machine VD{i € n) gen- 
erates a public/secret key pair (pk; skj)(i € n) and 
registers the pki € n) to the blockchain. To be 
more specific, the voting machine VD; generates 
a transaction Tregister With its pk; as well as the IP 
address, and also computes a simple zero-knowl- 
edge proof with the secret key sk; to prove the 
possession of pk; and then puts T,epister in the 
blockchain. After all the voting machines have 
registered their public keys, each VD; can locally 
compute the aggregated public key PK with all 
the legitimate pk;(i € n). 

Vote: In the Vote phase, four sub-phases are 
included, they are Commit, Cast, Tally, and Recov- 
er. Inthe Commit phase, each voting machine 
VD; chooses a vote v; and generates a corre- 
sponding commitment for v;. Then it puts the 
commitment into the transaction Teommit and logs 
it into the blockchain. Specifically, the commit- 
ment is generated with the selected vote v; and 
all the other devices’ public key pk,(j = i). In this 


Blockchain 


Tcommit 


FIGURE 3. Workflow of blockchain-based self-tallying voting system with software 


update. 


way, we can ensure the fairness, as if the voting 
machines are hacked by malware or break down 
so that they are not able to cast their ballots in 
the Cast phase, we can still recover the vote 
according to the commitment with the help of 
all the other voting machines’ secret key and get 
the final voting results. Here, VD; can also choose 
some of the voting machines it trusts to generate 
the commitment, then a subset, rather than all, 
of the voting machines are required to recover 
the vote. After the Commit phase, the set of the 
voters cannot be changed, since the correspond- 
ing public key are bound in the commitment. In 
the time slice of Cast, each voting machine VD; 
randomizes their selected vote v; with its own 
secret key sk; and other voting machines’ public 
key pk = i) to form a secret ballot aiming at 
protecting the privacy of the vote. Then each VD; 
casts the ballot into the blockchain. In this way, 
after all the voting machines’ ballots appear on 
the blockchain, each entity can collect the bal- 
lots in the system and compute the final voting 
result in the Tally phase, as the hiding factor in 
each secret ballot can be removed when they 
are aggregated. If some of the registerred vot- 
ing machines do not cast the ballot, the Recover 
phase can be activated, in which several other 
voting machines are required. To be more spe- 
cific, suppose a voting machine VD; computes 
its commitment with all the other pkj(j = i), and 
is injected with malware by some hacker that it 
cannot cast the ballot in the Vote phase. Then 
all the VD{j =) with their sk, = i) and pk; can 
get together to decommit the commitment and 
recover a vote to do the tally. 

Update: The vendors provide secure and reli- 
able updates for voting machines. When the ven- 
dors publish new patches for the voting machines, 
they will generate a smart contract on the block- 
chain with their signatures for authentication. 
Voting machines can download from the smart 
contract and install them for the update. 


ANALYSIS 


Compared to the existing solutions, our proposed 

framework has the following merits. 

* Decentralization: The proposed framework is 
fully decentralized. Based on the blockchain 
overlay, there is not any central party in the 
system, which eliminates the risk of a single- 
point-of-failure. 

e Fairness: The protocol is fair with the help of 
the commitment, homomorphic encryption 
and zero-knowledge proofs. 

* Self-Tallying: The voting protocol is self-tally- 
ing based on the algebraic manipulation if all 
the users follow the process. 

* Ballot Secrecy: The ballot secrecy is guaran- 
teed by the encryption of the ballots. The 
ballot secrecy is achieved if the underlying 
encryption scheme satisfies indistinguishability. 

* Software Update: The protocol can support 
software updates by the vendors via the 
blockchain by its design. 


PERFORMANCE AND EVALUATION 


In this section, we elaborate on the simulation 
results of the proposed construction. In the exper- 
iments, we first implement the protocols on a 
desktop. Then we test the efficiency of the con- 
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FIGURE 4. Implementation results: a) running time on the laptop; b) running time on the raspberry Pi. 


struction on a Raspberry Pi for a better simulation 
of the loT voting devices. 


ENVIRONMENT 


The desktop is equipped with an Intel® Core™ 
i7-7700 CPU 3.6 GHz and 16 GB RAM, whose 
operating system is Ubuntu 16.04.6 LTS. The 
Raspberry Pi 3 Model B+ is loaded with a 64-bit 
quad-core ARM v7 processor rev 4 and 1 GB 
LPDDR2 SDRAM. The operating system is Ubun- 
tu Mate 16.04.6 LTS. The project is written in C 
language with the GMP library (https://gmplib. 
org/) to deal with the operations among large 
integers. The modulus is fixed as a 1024-bit prime. 


EXPERIMENT RESULTS 


We test the efficiency of the algorithms includ- 
ing Register, Commit, Vote, and Tally. For each 
algorithm, we repeat 50 times and get the aver- 
age time consumption. We can see from the 
Figs. 4a and 4b that the time consumption for 
each algorithm is linear with the number of vot- 
ers in the system both on a laptop and a Rasp- 
berry Pi, which is consistent with the empirical 
analysis, as the more voters are involved in the 
system, the more calculations are needed in 
each algorithm. The most expensive algorithm is 
Commit, which takes 15.989 ms for 100 voters 
on a laptop and 199.878 ms for 50 voters on 
a raspberry Pi, respectively. The cheapest algo- 
rithm is Tally, as after the ballots are collected, 
only several multiplications are needed to tally 
the results; it costs less than 0.002 ms for 100 
voters on a laptop and 0.02 ms for 50 voters 
on a raspberry Pi to tally the results of the vot- 
ing. To cast ballots, it takes less than 20 ms for 
50 voters serially on a raspberry. For the voters 
on a laptop to cast the ballots, it costs less than 
3 ms for 100 voters, which is very efficient. To 
register as valid voters, the time consumption 
is almost 90 ms on a raspberry Pi for 50 vot- 
ers, and this is only a one-time phase. When it 
comes to the laptop, the corresponding time 
consumption for 100 voters is less than 6 ms, 
which enjoys high efficiency. 


CONCLUSION 


The Internet of things has been leading digital 
innovation and industrial revolution in recent 
years. Voting machines, one of the most widely 
used smart devices, have attracted our attention. 
In this article, we focused on the issues in voting 
protocols in decentralized loT and proposed a 
framework of blockchain-based self-tallying voting 
systems with software updates in decentralized 
loT. We developed a prototype to test the pro- 
posed framework, which proves it is practical and 
efficient. 
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